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(54) System zur Verifikation von Software-Anwendungsmodellen in Ketten von 
Software-Entwurfswerkzeugen 



(57) Die Erfindung bezieht sich auf ein System zur 
Verifikation von Software-Anwendungsmodellen in Ket- 
ten von Software-Entwurfswerkzeugen. Die Anwen- 
dungsmodelle sind Instanzen eines Metamodells sind, 
welches die Struktur von Modellen einer Software-An- 
wendung sowie Schnittstellen zu diesen Modellen be- 
schreibt, und auf dem alle Werkzeuge der Werkzeug- 
kette aufbauen. Das System beinhaltet ein Verifier-Fra- 
mework einschlieBlich einem Verifier-Manager sowie 
mehrere Verifizierer, wobei ein Verifizierer jeweils als ei- 
ne Gruppe von formulierten Bedingungen und Regeln 
fur jeweils eines der Modelle der Software-Anwendung 
gebildetwird, und mittelsdes Verifier- Managers Verifier- 
Gruppen im Verifier-Framework zur Prufung festgeleg- 
ter Modellelemente zusammengestellt werden. Das Sy- 
stem ist dafur eingerichtet, die Verifizierung von Soft- 
waremodellen bezuglich Vertraglichkeit mit den formu- 
lierten Bedingungen und Regeln mittels eines Uberpru- 
fungslaufs unter Verwendung des Metamodells vorzu- 
nehmen, wobei sich als Ergebnis die festgestellten Be- 
dingungs- oder Regelverletzungen ergeben. 
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Beschreibung 

[0001] Die Erfindung bezieht sich auf ein System zur Verifikation von Software-Anwendungsmodellen in Ketten von 
Software-Entwurfswerkzeugen. 

[0002] Bei der Erstellung von IT-Systemen kommen vermehrt Werkzeuge und wiederverwendbare Softwarebaustei- 
ne - auch Komponenten genannt - zum Einsatz, welche die Entwickler in ihrer Arbeit unterstutzen. Dabei gibt es eine 
nahezu unuberschaubare Menge an Werkzeug- und Komponententypen. Beispiele sind einfache Texteditoren zum 
Bearbeiten von Quellcode, Werkzeuge zur Erfassung von Anforderungen an ein Software-System, Design-Werkzeuge, 
Ubersetzer, Generatoren, Transaktionsmanagement-Systeme, Datenbanken pder ganze Ablaufumgebungen fur An- 
wendungen, sog. Application Server. Je nach Ausgestaltung eines Software-Entwicklungsprozesses werden viele sol- 
cher Werkzeuge zusammengefaBt und miteinander integriert, wobei sich zumeist definiert durch den ProzeB eine klare 
Reihenfolge erkennen laBt, in der die Werkzeuge in der Entwicklung zum Einsatz kommen. In solchen Fallen kann 
von einer Werkzeugkette gesprochen werden. Am Ende eines vollstandigen und korrekten Durchlaufs durch eine sol- 
che Kette steht ublicherweise ein lauffahiges Software-System. 

[0003] Es gibt im Bereich des computergestutzten Softwareentwurfs und der-entwicklung, auch CASE - Computer 
Aided Software Engineering genannt, eine Vielzahl von machtigen Werkzeugen, teils als kommerzielle Produkte kauf- 
lich, teils als kostenlose Software beispielsweise aus dem Internet beziehbar. Interessant ist hier vor allem die Be- 
trachtung bereits verfugbarer Werkzeug/ceften, die als solche ausgepragt sind. 

[0004] Hier sind zum einen die "klassischen" integrierten Entwicklungsumgebungen, sog. IDE - integrated Develop- 
ment Environment zu nennen, die sich in der Vergangenheit zumeist darauf beschrankten, eine nahtlose Integration 
zwischen Editor, Konstruktionshilfen fur graphische Benutzungsschnittstellen, Ubersetzer, Debugger und oftmals ex- 
ternen Werkezeugen wie z.B. Versionierungs- und Konfigurationsverwaltungswerkzeugen herzustellen. Nennenswerte 
Produkte in diesem Bereich sind SNiFF+ von der Firma TakeFive, jetzt WindRiver, JBuilder von der Firma Borland / 
Inprise, Symantec Cafe von der Firma Symantec Oder Visual C++/J++ von der Firma Microsoft. 
[0005] Zum anderen gibt es im Bereich der engeren Fassung des Begriffes CASE einige Werkzeugketten, die den 
Anwender von den fruhen Phasen des Entwurfs, also z.B. der Analyse und der Erfassung der Anforderungen begleiten 
bis hin zur Erzeugung des lauffahigen Software-Systems. Beispiele hierfur sind die Werkzeuge der Firma Rational, 
die Produkte der Firma Together Oder das Produkt ArcStyler von der Firma Interactive Objects Software GmbH. 
[0006] Auch im akademischen Bereich gab es Forschung zum Thema der Integration von Werkzeugen zum Soft- 
wareentwurf. Hier ist besonders zu erwahnen das Projekt STONE (siehe Eduardo Casais, Claus Lewerentz, STONE 
project monograph: Issues in Tool Integration, Forschingszentrum Informatik, Karlsruhe, ISSN 0944-3037), das zu 
Teilen am Forschungszentrum Informatik an der Universitat Karlsruhe TU durchgefuhrt wurde. 
[0007] Beim Durchlaufen einer Werkzeugkette gibt es zahlreiche potentielle Fehlerquellen. Daher bieten die meisten 
Werkzeuge eine mehr oder weniger gut ausgepragte Unterstutzung in der Auffindung und Behebung von Fehlern an. 
Ein eingangiges Beispiel fur die Fehlererkennung in solchen Werkzeugketten sind die syntaxbewuBten Quellcodeedi- 
toren. Dabei findet in der Regel eine farbliche Hervorhebung syntaktischer Elemente im Quellcode durch den Editor 
statt, so daB der Entwickler moglichst rasch und leicht Konstrukte im Code identif izieren kann, die von nachgeschalteten 
Werkzeugen, z.B. dem Ubersetzer, fur unzulassig erkannt wurden. So erspart dieses Vorgehen in manchen Fallen 
einen unnotigen Ubersetzerdurchlauf, der nur die bereits fruher erkennbaren Fehler aufgedeckt hatte, urn nach an- 
schlieBender Uberarbeitung der Eingaben wiederholt ausgefuhrt zu werden. 

[0008] Dabei wird jedoch explizit im vorgeschalteten Werkzeug, im Beispiel dem Editor, Wissen uber Randbedin- 
gungen eines nachgeschalteten Werkzeugs integriert. So enthalt beispielsweise ein im Werkzeug JBuilder yon der 
Firma Borland/ Inprise integrierter Editor zwar die Regeln fur die Syntax der Programmiersprache Java, nicht jedoch 
die der Sprache Fortran. Wurden also mit diesem Editor Fortran-Quellen bearbeitet, so konnte der Editor keine Unter- 
stutzung im Syntax-Bereich mehr bieten. Wichtig zu erkennen ist also hier die Integration des Wissens uber nachge- 
schaltete Werkzeuge als fester Bestandteil eines vorgeschalteten Werkzeugs beim Stand derTechnik. 
[0009] Fur Werkzeuge, welche die hoherwertige Semantik eines Software-Systems zu modellieren gestatten, sind 
solche antizipativen Fehlererkennungshilfen nicht verfugbar. Beispiele fur solche Werkzeugtypen sind Analysewerk- 
zeuge etwa zur Erfassung von Klassenkarten - die sog. Cf?C-Technik — Class, Responsibility, Collaboration - oder 
zur Beschreibung von Designs in Modellierungssprachen wie der UML — Unified Modeling Language (siehe auch 
James Rumbaugh, Ivar Jacobson, Grady Booch, The Unified Modeling Language Reference Manual, Addison Wesley 
Longman, Reading MA, 1999). 

[001 0] Erwahnenswert ist auch der Bereich der Emulation oder Simulation. Hier ahmen Softwaresysteme das Ver- 
halten anderer Systeme nach. Zum Beispiel gibt es Software-Emulatoren fur Mikroprozessoren. Der Nachteil emula- 
tiver Systeme ist, daB sie im Gegensatz zu einem Modell der Fahigkeiten eines Werkzeugs oder einer Komponente 
in der Regel keinerlei Verkurzungsaspekt gemaB der Modelltheorie aufweisen, also die Durchfuhrung bestimmter Uber- 
prufungen in keiner Weise vereinfachen. Anders gesagt ergibt sich durch Emulation in dem hier betrachteten Zusam- 
menhang kein Vorteil gegenuber der tatsachlichen Umschaltung in das betreffende Werkzeug, da nur das ganze Werk- 
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zeug selbst "dupliziert" wird, nicht jedoch seine fur die Fehleranalyse entscheidenden Regeln und Bedingungen. 
[0011] Ein weiterer Bereich, in dem Eigenschaften von Systemen, Werkzeugen und Komponenten beretts fruh in 
einem EntwurfsprozeB eine Rolle spielen, ist die Architektur, hier besonders der Bereich Hochbau. Dabei gehen die 
Eigenschaften etwa von Baumaterialien bereits in die Planungsphase ein. So beeinfluBt beispielsweise die Tragfahig- 
keit von Stahlbeton den Entwurf der Decken in einem Hochhaus. Im Architekturbereich ist jedoch eine Formalisierung 
dieses Prozesses nicht gegeben. Das Problem wird hier durch vermehrte Kommunikation zwischen den beteiligten 
Personen gelost. Beispielsweise werden in den PlanungsprozeB neben dem Architekten auch Bauingenieure Oder 
Statiker mit einbezogen, die dann den Architekten beim Entwurf unterstutzen und von ihm geplante Konstruktionen 
auf Machbarkeit uberprufen. 

[0012] Es ist eine zentrale Erkenntnis, nicht nur im Bereich der Informationstechnologie, daf3 die fruhzeitige Erken- 
nung und Behebung von Fehlern erheblich zur wirtschaftlichen Durchfuhrung von Entwicklungsprojekten beitragt. Mit 
wenigen Ausnahmen, z.B. vorgenannte Quellcode-Editoren, existiert jedoch eine antizipative Fehlererkennung entlang 
einer Werkzeugkette im Bereich des Softwareentwurfs bisher nicht. Dadurch werden viele Fehler erst spat in der Kette 
entdeckt, und es vergroBert sich somit die Anzahl an Durchlaufen durch den Entwicklungszyklus zur Behebung dieser 
Fehler. Das ist aufwendig und kostet viel Zeit und Geld. 

[0013] Ein ursachliches Problem ist dabei die Sicht eines jeden Werkzeugs entlang einer Kette, die eingeschrankt 
ist auf die von ihm bearbeiteten Aspekte des Gesamtsystems. Eine ganzheitliche Sicht fehlt. 
[0014] Auch sind die wenigen vorhandenen Mittel, wie etwa Syntaxhervorhebung in Quellcodeeditoren, nur mit ge- 
ringem semantischen Wissen uber die tatsachlich zu prufenden Bedingungen ausgestattet. Zum Beispiel konnen die 
meisten Quellcodeeditoren zwar Schlusselworter der Zielsprache erkennen und entsprechend hervorheben; die Uber- 
prufung, ob die Verwendung des Schlusselwortes an diese Stelle zulassig ist, unterbleibt jedoch in alter Regel. 
[0015] Etwas weiter geht hier der Ansatz, den Werkzeuge im Bereich der Softwareentwicklung mit der Programmier- 
sprache Smalltalk verfolgen. Dort sind der Quellcodeeditor und die syntaktische und semantische Analyse des Codes 
eng miteinander verwoben. Man konnte soweit gehen und von einem integrierten Werkzeug sprechen. Dadurch wird 
zwar auf der einen Seite eine rasche und einfache Prufung des Quelltextes moglich, auf der anderen Seite ist die 
Anpassung der zu prufenden Regeln und damit die Verwendung des Editors mit einer anderen Programmiersprache 
nicht mehr moglich. 

[0016] Ein weiterer entscheidender Punkt ist, daB durch die Vielzahl verfugbarer Werkzeuge und Komponenten die 
daraus ableitbare Anzahl von verschiedenen moglichen und sinnvollen Werkzeug ketten sehr groB ist. So konnte bei- 
spielsweise ein DesignWerkzeug prinzipiell zwar erkennen, daB ein bestimmtes Design nicht auf das gewahlte Daten- 
bankprodukt abbildbar ist, aber dazu fehlt es bis jetzt den Designwerkzeugen an offenen Schnittstellen, uber die eine 
Beschreibung der Regeln nachfolgender Werkzeuge und Komponenten so erfolgen kann, daB sie vom Designwerk- 
zeug uberpruft werden konnten. 

[0017] Daraus ergeben sich nachfolgend Probleme, soli einmal ein Werkzeug Oder eine Komponente in der Kette 
ausgetauscht werden. Im schlimmsten Fall treten bestimmte Fehler erst in einem ausgelieferten System auf, weil sie 
zuvor unentdeckt blieben. Wahrend man heute diesen Problemen durch massiven Testaufwand im Vorfeld einer Aus- 
lieferung begegnet, konnen durch verbesserte Werkzeugunterstutzung bei der Fruherkennung von Fehlern diese Auf- 
wande erheblich reduziert werden. 

[0018] Der Erfindung liegt die Aufgabe zugrunde, ein System anzugeben, das es ermoglicht, entlang einer Werk- 
zeugkette fruhzeitig im EntwurfsprozeB Fehler in dem im Entwurf befindlichen Software-Anwendungsmodell zu erken- 
nen, und zwar ubergreifend uber die Aspekte aller beteiligten Werkzeuge und Komponenten entlang der Kette. 
[0019] Diese Aufgabe wird gelost durch ein System zur Verifikation von Software-Anwendungsmodellen in Ketten 
von Software-Entwurfswerkzeugen mit den im Anspruch 1 angegebenen Merkmalen. Vorteilhafte Ausgestaltungen 
sind in weiteren Anspruchen angegeben und der nachstehenden Beschreibung von Ausfuhrungsbeispielen zu ent- 
nehmen. 

[0020] Bei der Erfindung handelt es sich urn ein System, das es ermoglicht, Bedingungen und Regeln fur ein Soft- 
ware-Anwendungsmodell so zu formulieren, daB sie anschlieBend auf ein bestehendes Software-Anwendungsmodell 
angewendet und das Modell somit auf Vertraglichkeit mit diesen Bedingungen und Regeln uberpruft werden kann. Die 
Regeln/Bedingungen konnen dabei zu Gruppen zusammengefaBt werden, die beispielsweise jeweils aus der Sicht 
eines einzelnen Werkzeugs Oder einer einzelnen Komponente formuliert sind. Die Anwendung und Uberprufung der 
Regeln kann jedoch unabhangig von einem bestimmten Werkzeug zu beliebiger Zeit an beliebiger Stelle in der Werk- 
zeugkette stattfinden. Die Gesamtmenge der jeweils gOltigen Regeln/Bedingungen ergibt sich dann aus der Kombi- 
nation derjenigen Regelgruppen zu den Werkzeugen und Komponenten, die in der verwendeten Werkzeugkette ar- 
rangiert wurden. 

[0021 ] Die Beschreibung der Regeln erfolgt unter Verwendung der Schnittstelle des Modells, welche durch ein Me- 
tamodell definiert wird. Neben dem Modell kann eine Regel auf eine vom Software-Anwendungsmodell unabhangige 
Parametermenge zugreifen, welche beispielsweise die Fahigkeiten einer eingesetzten Softwarekomponente be- 
schreibt und somit Anforderungen an das Modell beschreibt und / Oder parametriert. 
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[0022] Das System laBt sich in folgende Teile untergliedern, die im AnschluB detailliert erlautert werden: 
[0023] Grundlage ist das Metamodell, welches die Struktur von und Schnittstellen zu Modellen von Software-Syste- 
men beschreibt und auf dem alle Werkzeuge in einer Kette aufbauen. Die Regeln und die diese uberprufenden Algo- 
rithmen sind in einem sogenannten Ver/f/erFramewor/fzusammengefugt. Regeln konnen flexibel parametriertwertien, 
5 wobei ein spezielles Verfahren die Wiederverwendung von Parametergruppen erlaubt. Zuletzt wird noch die Integration 
der Regelprufung in eine Werkzeugkette beschrieben. 

Metamodell 

w [0024] Als Grundlage des hier verwendeten Metamodellsfur die Beschreibung von Modellen von Software-Systemen 
wird hier der UML-Standard eingesetzt. Damit sind die Basiselemente eines objektorientierten Software-Systems be- 
schreibbar, beispielsweise Classifier, Namespace, Operation, Parameter oder Generalization. Die Erfindung ist jedoch 
auch auf Erweiterungen eines solchen Standard-Metamodells, z.B. UML profiles, oder auf beliebige andere Meta- 
modelle anwendbar, z.B. wenn das Modell zusatzlich Zusammenhange zwischen Teilen einer Komponente zu be- 

15 schreiben erlaubt, wie dies der CCM - CORBA Components Standard vorsieht oder wenn Quellcodeelemente als Teile 
des Modells beschrieben werden. 

[0025] Es muB eine definierte Schnittstelle geben, uber die auf Instanzen des Metamodells, also auf Modelle von 
Software-Systemen, zumindest lesend zugegriffen werden kann. Dabei mussen uber diese Schnittstelle die Eigen- 
schaften der im Modell beschriebenen Elemente und deren Beziehungen untereinander abfragbar sein. 

20 

Verifier Framework, Anwendung von Verifiern auf Modellelemente 

[0026] Wie bereits oben erwahnt werden Regeln zu Gruppen zusammengefaBt. Diese Gruppen werden mit dem 
Begriff Verifier bezeichnet. Das Verifier Framework regelt nun das Zusammenspiel der einzelnen Verifiers und deren 
25 Ausfuhrung / Uberprufung gegen ein bestehendes Modell. 

[0027] Grundidee des Frameworks ist es, eine Menge von Verifiern auf eine Menge von Modellelementen anzuwen- 
den und dabei alle gefundenen Regelverletzungen aufzuzeichnen. Zu diesem Zweck muB das Framework folgende 
Fahigkeiten bieten: 

30 o Zusammenstellung einer Menge anzuwendender Verifier 

° Festlegung der Menge von Modellelementen, auf die die Menge von Verifiern anzuwenden ist 

Ausfuhrung der Verifier auf alien zuvor festgelegten Modellelementen bei gleichzeitiger Protokollierung aller test- 
35 gestellten Regelverletzungen 

menschen- und maschinenlesbare Presentation der gefundenen Verletzungen sowie konstruktive Fehlerbehe- 
bungshilfen 

40 [0028] Die Zusammenstellung der anzuwendenden Verifier erfolgt durch eine eigens daf ur vorgesehene Komponen- 
te, den Verifier Manager. Uber diese konnen dem Framework Verifier bekanntgegeben werden. Einzelne Verifier kon- 
nen damit dynamisch zu einem Uberprufungslauf hinzugenommen oder abgeschaltet werden. Dies kann dabei ent- 
weder programmatisch durch eine Anwendung geschehen, die sich der Funktionalitat des Verifier Frameworks bedient, 
oder durch eine eigene interaktive Benutzungsschnittstelle des Frameworks. 

45 [0029] Die Auswahl der Modellelemente, auf die die festgelegten Verifier anzuwenden sind, erfolgt durch explizite 
Auflistung. Zusatzlich kann fur solche Modellelemente, die weitere Modellelemente enthalten, z.B. ein Package, fest- 
gelegt werden, ob die Regeln bei einem Durchlauf auch transitiv auf die enthaltenen Elemente angewendet werden 
sollen. Urn also beispielsweise das gesamte Modell auf RegelverstoBe zu uberprufen, mussen lediglich die Package- 
Modellelemente, die sich nicht in weiteren Pac/cage-Strukturen geschachtelt befinden, ausgewahlt werden, und die 

50 Regeln mussen transitiv auf alle enthaltenen Modellelemente angewendet werden. Dadurch wird dann das gesamte 
Modell erfaBt. 

[0030] Bei der Ausfuhrung der Verifier gegen die Modellelemente nutzt das Framework die Tatsache aus, daB jeder 
Verifier eine- jeweils die gleiche - Schnittstelle zur Ubergabe eines Modellelements zur Uberprufung durch diesen 
Verifier unterstutzen muB. Somit kann das Framework homogen und durch Ausnutzung der objektorientierten Technik 
55 der Polymorphie jedem registrierten und ausgewahlten Verifier jedes zur Uberprufung anstehende Modellelement uber 
diese Schnittstelle zur Prufung vorlegen. Das Ergebnis einer jeden solchen Prufung ist eine Liste gefundener Regel- 
verletzungen, die jeweils genugend information enthalten mussen, urn daraus eine informative Meldung fur den An- 
wender abzuleiten, so daB fur diesen der gefundene VerstoB eindeutig identifizierbar und somit behebbar wird. Entlang 
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der Ausfuhrung aller selektierten Verifier auf alle festgelegten Modellelemente werden diese Regelverletzungslisten 
gesammelt und zusammengefugt, so daB am Ende eine einzige Gesamtliste entsteht, die dem Anwender prasentiert 
werden kann. 

[0031 ] Es ist hierbei wichtig zu erwahnen, daB eine Regel auch spezifisch fur bestimmte Arten von Modellelementen 
s sein kann. Es ist die Aufgabe des Verifiers, zu bestimmen, welche seiner enthaltenen Regeln er tatsachlich auf ein an 
inn zur Uberprufung ubergebenes Modellelement anwendet. 

[0032] Bei der Prasentation der Regelverletzungen werden folgende Aspekte einer Verletzung berucksichtigt: Die 
Schwere der Verletzung, also z.B. "Warnung" oder "Fehler", Auswirkungen des Fehlers Oder der Warnung, z.B. Per- 
formance-EinbuGen, ein informativer Text im Sinne einer Fehlermeldung, konstruktive Hinweise zur Behebung des 
10 Fehlers und eine Liste beteiligter Modellelemente, aus der fur den Anwender ablesbar ist, an welcher Stelle im Modell 
genau die Verletzung vorliegt und mitunter wie sie zustandekommt. Wenn das Werkzeug, in das die Prufung integriert 
ist, die Kenntlichmachung von Modellelementen unterstutzt, kann diese Eigenschaft ausgenutzt werden, urn die be- 
teilgten Modellelemente hervorzuheben. Diese Attribute der gefundenen Regelverletzungen lassen sich elegant in 
einer graphischen Prasentation zusammenfugen. 

75 

Flexible Parametrierung von Verifiern und die Uberladungssemantik bei der Beschreibung dieser Regeln in Sequenzen 
von XML-Dateien 

[0033] Das bisher Gesagte laBt weitestgehend offen, wie die Regeln und die durch sie ausgedruckten Anspruche 
20 an das Modell formuliert werden. Soweit wurde nur gefordert, daB das Metamodell die Schnittstelle vorgibt, uber die 
die Regeln auf das zu prufende Modell des Software-Systems zugreifen konnen. Es gibt jedoch Randbedingungen, 
die weitergehende Uberlegungen rechtfertigen: 

[0034] Oftmals erfullen Komponenten und Werkzeuge entlang einer Werkzeugkette bestimmte Standardaufgaben, 
fur deren Erledigung nicht ausschlieBlich das spezielle, ausgewahlte Werkzeug in Frage kommt. Andere Werkzeuge 
25 und Komponenten mogen weitestgehend die gleichen Anforderungen erfullen, moglicherweise jedoch jeweils mit ge- 
wissen Abweichungen und Unterschieden. Daraus lassen sich entsprechend unterschiedliche Verifier ableiten, die 
zum einen Standardregeln, zum anderen spezielle Regeln fur die Abweichungen des gewahlten Werkzeugs bzw. der 
gewahlten Komponente ausdrucken mussen. 

[0035] Dieser Anforderung tragt der bisher beschriebene Teil des Verifier Frameworks nur bedingt Rechnung. Die 
30 Standardregeln konnten in separaten Verfiern ausgedruckt werden, die Regeln zu den Abweichungen in wieder an- 
deren Verifiern. Der Verifier fur ein Werkzeug bzw. eine Komponente ergibt sich dann durch Zusammenfugen der 
Verfier fur die Standardregeln mit den Verifiern fur die Abweichungen. 

[0036] Oft sind die Unterschiede jedoch so beschaffen, daB ein eigener Verifier nicht gerechtfertigt erscheint und 
stattdessen die Parametrierung von Regeln angemessener ist. In solchen Fallen kommen parametrierbare Verifier 

35 zum Einsatz. Entscheidend dabei ist, daB Parametersatze fur Standardregeln festlegbar sind, die dann im Falle von 
Abweichungen gezielt abgeandert und erweitert werden konnen, ohne dabei die Parameterfestlegungen fur die Stan- 
dardregeln selbst modifizieren oder kopieren zu mussen. Nur so ist gewahrleistet, daB verschiedene Parametersatze 
gleichzeitig aus den Standardsatzen ab/e/fbar sind, Anderungen an den Standardparametern sich auf alle abgeleiteten 
Satze auswirken, die diese Anderungen nicht bereits speziell umdefinieren und daB die Standardparameter fur weitere 
- 40 Ableitungen wiederverwendbar bleiben. 

[0037] Dieses Prinzip lehnt sich an die Technik der Vererbung in objektorientierten Software-Systemen an, wo Klas- 
sen Eigenschaften definieren konnen, die dann von abgeleiteten Klassen uberladen werden konnen. Auch dort sind 
die Ziele die Wiederverwendung der Oberklasse, die automatische Propagierung von Anderungen und Erweiterungen 
der Oberklasse auf bestehende Unterklassen und die Moglichkeit der flexiblen Anpassungen der Unterklassen auf die 

45 geanderten Anforderungen der Spezialisierung, die sie gegenuber der Oberklasse darstellen. 
[0038] Es ergeben sich folgende Merkmale fur die Formulierung von Parametern: 

• Parameter werden zu Parametersatzen zusammengefaBt 

so o Parameter sind innerhalb eines Namensraumes eindeutig identifizierbar 

• Es kann eine Sequenz mehrerer Parametersatze in einem Namensraum vereinigt werden, wobei durch die Rei- 
henfolge eine Uberladungssemantik fur Parameter gleichen Namens im Kontext dieses Namensraumes definiert 
wird. 

55 

Formalisierung der Uberladungssemantik: 

[0039] Sei s := (s 1t s r } eine Sequenz von Parametersatzen mit S/ := {(n lv p n ), ... , (n im(i) ,p im(i) ) }. Der Satz mit der 
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Ordnungsnummer i besteht also aus einer Menge von m(i) Paaren, deren erstes Element den Namen des Parameters 
im Namensraum und deren zweltes Element den Parameterwert angibt. Dann ergibt sich der Wert p des Parameters 
mit dem Namen n im Kontext der Sequenz von Parametersatzen s mit obiger Definintion wie folgt: 

5 

\ undefinieit sonst 

10 Implementierung mit Sequenzen von XML-Dateien 

[0040] Eine Implementierung dieser Semantik kann z.B. so erfolgen, daB s abgebildet wird auf eine Sequenz von 
XML-Dateien {d 1t ... , d r }. Fur eine Beschreibung des XML-Standards siehe auch Brett McLaughlin, Mike Loukides, 
Java and XML, first edition, O'Reilly & Associates, June 2000, ISBN 05960001 62. Der Namensraum ist bestimmt durch 

is die Ausdrucksmoglichkeiten von XML, das im wesentlichen zwischen sogenannten Elementen und Attributen unter- 
scheidet. Element- und Attributstruktur konnen vorgegeben werden durch die fur d 1t c/ r einheitliche DTD — Docu- 
ment Type Definition. Dabei sind Elemente benannt und konnen geschachtelt werden; jedes Element kann eine Menge 
von benannten Attributen aufweisen, die jeweils einen Wert zugewiesen haben konnen. Weiterhin konnen Elemente 
beliebigen Text in einem Textkorper enthalten, der jedoch hier nicht weiter betrachtet werden soil. 

20 [0041] Der Name la&t sich somit eindeutig als ein Elementpfad, also ein Pfad im Gegensatz zu einem einfachen 
Namen aufgrund der potentiellen Schachtelung der Elemente, und abschlieBend den Namen des Attributs des letzten 
Elements in diesem Pfad formulieren. Der Parameterwert ist definiert als der Wert des ausgewahlten Attributes. Er 
kann somit alle Werte annehmen, die ein XML-Attribut annehmen kann. 

[0042] EineXML-Datei d/beschreibt also einen Parametersatz s h Ein Name n wird realisiert als Pfad, der die Namen 
25 von geschachtelten Elementen in der Schachtelungsreihenfolge und am Ende den Namen eines Attributs des innersten 
Elements enthalt. Der Wert des Attributs in der XML-Datei stellt den Wert des Parameters innerhalb des Satzes s,dar. 
Die Uberladungssemantik kann dann wie oben formalisiert angewendet werden. 

Veranschauiichung, Vorzuge: 

30 

[0043] Bildlich gesprochen ergibt sich durch dieses Verfahren ein "Stapel" von Dateien, die erste Datei d 1 der Liste 
zuunterst, die letzte d r zuoberst, wobei gleichnamige Parameter ubereinanderliegen, "undurchsichtig" sind und somit 
"weiter unten" liegende Parameterwerte uberdecken, wohingegen Parameter nach oben "durchscheinen", wenn dar- 
uberliegende Dateien sie nicht uberladen. Siehe dazu die Abbildungsfiguren Fig. 3 bis Fig. 7. 
35 [0044] In dieser Anordnung reprasentieren die weiter unten liegenden Dateien die Standards, die dann von spezi- 
elleren Parametern fur die Abweichungen angepaGt werden konnen. 

[0045] Mit dieser Implementierung sind Parametersatze z.B. mit einem einfachen Texteditor bearbeitbar; eine Ober- 
setzung als ein separater Schrittzur Nutzbarmachung dieser Informationen, wie dies etwa bei Implementierung eines 
Parametersatzes als Java-Programm anfallen wurde, entfallt. 
40 [0046] Ein parametrierbarer Verifier hat nun neben dem Zugriff auf das Modell des Softwaresystems zusatzlich die 
Menge definierter Parameter zur Verfugung, die sich aus der Zusammenstellung der beschriebenen Sequenz von 
XML-Dateien ergibt und kann deren Werte in die Auswertung der Regeln mit einbeziehen. 

Integration des Verifier Frameworks in Werkzeugketten 

45 

[0047] Die Art und Weise, auf die die Regelprufung in die Werkzeugkette integriert wird, hangt stark von der Be- 
schaffenheit der Kette selbst ab, unter anderem von der Semantik der einzelnen Schritte und der Erweiterbarkeit der 
verwendeten Werkzeuge. Elegant, aber nicht zwingend notwendig, ist naturlich die Integration in ein bestehendes 
Werkzeug hinein, so daB die Regelprufung noch im Werkzeug selbst erfolgen kann und somit die Zeit und der Aufwand 
so fur das Hin- und Herschalten zwischen Werkzeug(en) und Regelprufung entfallt. 

[0048] Bieten die Werkzeuge diese Funktionalitat jedoch nicht, so kann dennoch eine Regelprufung durch Ausfuh- 
rung als separates Werkzeug erfolgen, welches dann an einer oder mehreren Stellen in die Werkzeugkette integiert 
wird. 

[0049] Eine weitere Erlauterung der Erfindung erfolgt anhand von Zeichnungsfiguren. Es zeigen: 

55 

Fig. 1: Ubersicht Verifier Framework am Beispiel UML/Java/J2EE, 
Fig. 2: Fehlerhaftes Modell, 

Fig. 3: Veranschauiichung der Uberladungssemantik von Parametersatzen, 
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Fig. 4: Standardparameter fur einen parametrierbaren Verifier, 
Fig. 5: Erste Uberladung von Parametern fur einen parametrierbaren Verifier, 
Fig. 6: Zweite Uberlagung von Parameters fur einen parametrierbaren Verifier und 
Fig. 7: Ergebnis der angewendeten Uberladungssemantik. 

5 

[0050] Die Diagramme in diesem Abschnitt orientieren sich an der UML-Notation. 

[0051 ] Fig. 1 zeigt den Verifier Manager, seine Beziehung zu den Verifiern und die Struktur der verschiedenen Verifier. 
Der Manager kennt eine beliebige Anzahl von Verifiern. Dabei ist Vertf/er selbst nur eine Schnittstellenbeschreibung, 
wie am Stereotyp «interface» zu erkennen ist, welche die Methodenschnittstelle zum Anwenden des Verifiers auf ein 

10 Modellelement definiert. Im Bild sind verschiedene Verifier-Varianten gezeigt, unter anderem ein Verifier, der das Modell 
auf UML-Regeln prufen soli, im Beispiel der UMLVerifier, einer, der es auf Regeln der Sprache Java uberprufen soli 
und ein parametrierbarer Verifier, der die J2EE-spezifischen Regeln prufen soil. Eine Beschreibung des ^EE-Stan- 
dards findet sich beispielsweise in Paul Perrone, Venkata S.R.K.R. Chaganti, Building Java Enterprise Systems with 
J2EE, Sams; June 2000, ISBN: 0672317958. Im Bild ist die wichtige Beziehung zwischen den Verifier-lmplementie- 

15 rungen und der t/er/rVer-Schnitts telle festgehalten: Die konkreten Verifier implementierendle Verifier-Schnittstelle, kon- 
nen somit dem Verifier Manager bekanntgegeben werden, und dieser kann sie polymorph verwenden, urn Modellele- 
mente durch sie prufen zu lassen. 

[0052] Fig. 2 zeigt ein beispielhaftes Modell. An ihm soli die Anwendung einer Menge von Verifiern auf eine Menge 
von Modellelementen erlautert werden. Es sei das Verifier-Model! aus Fig. 1 zugrunde gelegt. Auf das in Fig. 2 gezeigte 

20 Package P soil also die folgende Liste von Verifiern angewendet werden, und zwar auch auf seine enthaltenen Ele- 
mente: <UML Verifier, Java Venfier>. Dabei prufe der UML Verifier6\e Regel, daB ein Interface nie ein Nicht-lnterface 
spezialisieren kann. Der Java Verifier prufe die Bedingung, daB kein Classifier mehr als ein Attribut mit demselben 
Namen enthalt. Nun wird zuerst der UMLVerifier auf Package P angewendet. Fur ein Package wendet der Verifier im 
Beispiel keine Regel an. AnschlieBend, da auch alle enthaltenen Modellelemente des Packages zu verifizieren sind, 

25 wird dem Verifier der Reihe nach Modellelement A, dann B und dann C ubergeben. Wahrend bei A und C keine Regel 
des UML Ifer/ffers verletzt ist, entdeckterbei B, daB hier ein Interface, namlich B, ein Nicht-lnterface, hiervAspezialisiert. 
Damit ist eine Regel verletzt, und es wird eine entsprechende Fehlermeldung mit den Classifiern A und B als beteiligten 
Modellelementen zusammen mit einer beschreibenden Fehlermeldung in die Ergebnisliste eingefugt. 
[0053] Der JavaVerifier bekommt auf die gleiche Weise die Classifier A, B und C ubergeben und stellt bei A die 

30 Verwendung zweier Attribute mit dem gleichen Namen fest. Damit ist eine seiner Regeln verletzt und es wird wieder 
ein Fehlerprotokoll an die Ergebnisliste angehangt. 

[0054] Fig. 3 zeigt die Uberlagerung mehrerer XML-Dateien zur Definition von Parameterwerten, auf die ein para- 
metrierbarer Verifier zugreifen kann. Im Beispiel sind drei Dateien dargestellt: eine zur Beschreibung von Standard- 
parametern, eine zur Uberlagerung und Erweiterung der Standardparameter mit speziellen Werten fur ein Produkt X, 

35 und eine dritte fur zusatzliche Erweiterungen und Umdefinitionen fur ein weiteres Produkt V. Die Grafik soil verdeutli- 
chen, daB in dieser Anordnung "weiter oben" liegende Parameterwerte solche, die "weiter unten" liegen, verdecken. 
[0055] Die Abbildungsfiguren Fig. 4 bis Fig. 7 zeigen ein Beispiel fur die Uberlagerung mehrerer Parameterdateien. 
Fig. 4 zeigt die Menge der Standardparameter. Fig. 5 zeigt die Parameter fur Werkzeug / Komponente Xund Fig. 6 
zeigt diejenigen fur Werkzeug / Komponente Y. Fig. 7 schlieBlich zeigt das Ergebnis der Uberlagerung in der Reihen- 

40 folge <Standard, X, Y>. 

[0056] Das ganze sei nochmals am Beispiel aus Fig. 2 demonstriert. Gegeben seien die folgenden XML-Parameter- 
dateien defaultcap, associations. cap und ejbContainerX.cap mit den folgenden auszugsweisen Inhalten: 

default.cap: 

45 
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Associations 

InterfaceFromInterface=" supported" 
Interf aceFromClass=" supported" 
ClassFromClass=" supported" 



/> 



15 associations.cap: 



20 



Associations 

c01-01=" supported" 
c01-0n=" nonsupported" 
25 c0n-0n=" nonsupported" 

/> 



30 



35 



40 



45 



ejbContainerX.cap: 

Associations 

cO 1 - 0n= " supported" 

/> 



[0057] Der J2EEVerifierpruie die Multiplizitaten der im Model! auftretenden Assoziationen zwischen Classifiern und 
die Stereotypen der Classifier an den Assoziationsenden, also z.B. ob eine Beziehung zwischen Interface und Class 
zulassig ist, oder ob eine Beziehung zwischen zwei Interfaces erlaubt sein soil. Die Menge der erlaubten Multiplizitaten 
werde dabei aus den angegeben XML-Parameterbeschreibungsdateien gewonnen, und zwar im ersten Durchlauf mit 

so der Dateiliste <defaullcap, associations.cap>. Bekommt der Verifier das Modellelement ubergeben, welches die As- 
soziation aus Fig. 2 zwischen C und B pruft, dann werden folgende Parameter angefordert: associations: I nterfaceF- 
romClass, da es sich urn eine Assoziation von einem Classifier ohne speziellem Stereotyp, also "Class" und einem 
Classifier mit dem Stereotyp ""interface »" handelt; und associations:c01-0n, da das eine Assoziationsende die Multi- 
plizitat "0..1" und das andere H 0..n" aufweist. Wahrend der Verifier fur den ersten Parameter "supported' als Wert erhalt, 

55 was die Beziehung zwischen Class und Interface fur erlaubt erklart, erhalt er fur den zweiten Parameter den Wert 
n not_supportecT, wie in associations.cap definiert. Es wird folglich ein Fehlerreport erzeugt, der die B und Cals beteiligte 
Modellelemente nennt und auf die Verletzung der erlaubten Multiplizitaten hinweist. 

[0058] Wird nun zu der Liste der Dateien noch die Datei ejbContainerX.cap hinzugenommen, ergibt sich die Liste 



8 



EP1 202166 A1 



<defautt.cap, associations.cap, ejbContainerX.cap>. Wird mit dieser Liste der zuvor beschriebene Durchlauf wieder- 
holt, so meldet der Verifier diesmal keine Regelverletzung, da die Multiplizitatenkombination 0.. 1/0.. n durch die Angabe 
in ejbContainerX.cap als "supported" erklart wurde. So kann also ohne einen Eingriff in den Verifier seine Regelmenge 
einfach und unter Einhaltung der zuvor genannten Bedingungen wie etwa Wiederverwendbarkeit der Standardpara- 
meterwerte erweitert / modifiert werden. 



Patentanspriiche 

1. System zur Verifikation von Software-Anwendungsmodellen in Ketten von Software-Entwurfswerkzeugen, wobei 

a) die Anwendungsmodelle Instanzen eines Metamodells sind, welches die Struktur von Modellen einer Soft- 
ware-Anwendung sowie Schnittstellen zu diesen Modellen beschreibt, und auf dem alle Werkzeuge der Werk- 
zeugkette aufbauen, 

b) ein Verifier-Framework einschlieBlich einem Verifier-Manager sowie mehrere Verifizierer existieren, wobei 
ein Verifizierer jeweils als eine Gruppe von formulierten Bedingungen und Regeln fur die Modelle von Software- 
Anwendungen gebildet wird, und mittels des Verifier-Managers Verifier-Gruppen im Verifier-Framework zur 
PrOfung festgelegter Modellelemente zusammengestellt werden, und 

c) das System dafur eingerichtet ist, die Verifizierung von Softwaremodellen bezuglich Vertraglichkeit mit den 
formulierten Bedingungen und Regeln mittels eines Uberprufungslaufs unter Verwendung des Metamodells 
vorzunehmen, wobei sich als Ergebnis die festgestellten Bedingungs- Oder Regelverletzungen ergeben. 

2. System nach Anspruch 1, dadurch gekennzeichnet, daB das Metamodell auf dem UML(Unified Modeling Lan- 
guage)-Standard basiert. 

3. System nach einem der vorstehenden Anspruche, dadurch gekennzeichnet, daB es dafur eingerichtet ist, pa- 
rametrierbare Verifier zu bilden und zu verwenden, die es ermoglichen, in der Regelformulierung neben dem An- 
wendungsmodell auch auf die Werte dieser Parameter zuzugreifen und somit die Regeln durch Parametersatze 
anzupassen, ohne die Regeln selbst andern zu mussen. 

4. System nach einem der vorstehenden Anspruche, dadurch gekennzeichnet, daB der Verifier-Manager defur 
eingerichtet ist.einzelne Verifier dynamisch zu einem Uberprufungslauf hinzuzunehmen oder abzuschalten. 

5. System nach Anspruch 4, dadurch gekennzeichnet, daB der Verifier-Manager dafur eingerichtet ist, die dyna- 
mische Zu- Oder Abschaltung von Verifiern programmatisch durchzufuhren, oder es zu ermoglichen, daB sie durch 
ein Anwenderprogramm erfolgt, das sich der Funktionalitat des Verifier-F ram works bedient, oder durch eine eigene 
interaktive Benutzungsschnitts telle des Verifier-Fram works. 

6. System nach einem der Anspruche 3, 4 oder 5, dadurch gekennzeichnet, daB es dafur eingerichtet ist, Parame- 
tersatze fur parametrierbare Verifier aus Sequenzen von Parametersatzen zusammenzusetzen, bei denen entlang 
der Sequenz Parameterwerte uberladen werden. 

7. System nach Anspruch 6, gekennzeichnet dadurch, daB die Parametersatze fur paramerierbare Verifier in Text- 
dateien im ASCII-Format abgelegt sind. 

8. System nach Anspruch 7, dadurch gekennzeichnet, daB als innere Struktur der Textdateien das XML-Format 
verwendet ist. 

9. System nach einem der vorstehenden Anspruche, dadurch gekennzeichnet, daB das System in der Program- 
miersprache Java erstellt ist. 



9 



EP 1 202 166 A1 






















<D 






53 






* c 










> 




S 












O 
























> 



F/g. f; Ubersicht Verifier Framework am Beispiel UMUJava/J2EE 



10 



EP 1 202166 A1 



Package P 



numberrString 
number: int 











c 


0..1 0..n 
► 


«interface» B 








verifyModelElementQ 



Fig. 2: Fehlerhaftes Modell 
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Fig. 3: Veranschaulichung der Uberladungssemantik von Parametersatzen 
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Fig. 4: Standardparameter fur einen parametrierbaren Verifier 
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Fig. 5: Erste Uberladung von Parametern fur einen parametrierbaren Verifier 
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Fig. 6: Zweite Uberladung von Parameters fur einen parametrierbaren Verifier 
Parameter der Liste <Standard, X, Y> 
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Fig. 7: Ergebnis der angewendeten Uberladungssemantik 
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